PROVIDING HIGHLY AUTOMATED PROCUREMENT SERVICES 



BACKGROUND 

In a typical business transaction, a customer (whether an individual consumer 
or a business entity) initiates the transaction by placing a purchase request with a 
seller/agent via a communication means such as telephone, mail, facsimile, private 
networks (e.g., electronic data interchange (EDI)), Internet (e.g., email), or other 
communication networks, as appropriate. A seller/agent often does not manufacture 
the products it sells but obtains them from various suppliers. For example, a 
bookstore, which accepts purchase requests from customers for books, generally 
obtains the books from one or more publishers. 

Such business transactions (e.g., transactions involving at least a customer, a 
seller/agent, and a suppher) are typically handled in a mostly manual fashion within 
the seller/agent's organization. Manual processes are time consuming, prone to error, 
and generally not capable of real time status inquiries. For example, external entities 
in a transaction, such as customers and suppUers, do not have ways to directly 
communicate with each other (either at all or at least not in real time). Typically, 
external entities have to communication via the seller/agent. In addition, when a 
customer or a suppUer makes a change after the original order has been placed, the 
change again needs to be processed manually via the seller/agent, thus, causing more 
delays and possibilities for error in the fransaction. 

There exist several commercially available so-called enterprise resource 
planning (ERP) software programs capable of linking computer systems or resources 
in various departments within a company. These software programs are made by 
Baan, SAP, PeopleSoft, J.D. Edwards, Oracle, and other companies. When properly 
installed and configured, such software may provide automation within a company by 
supporting proper organization and updating of a central internal database accessible 
by all departments within the company. The central internal database is typically not 
directly accessible by any external entities, such as customers and suppHers. 



In an ad hoc solution to the foregoing, some companies have created a 
duplicate external database to permit limited access by external entities. However, 
this approach typically requires custom interfaces between the internal and external 
databases, which in turn require additional investment to develop and maintain. 

Further, the duplicate external database typically has to be periodically 
synchronized with an internal central database. For example, information regarding 
inventory levels or prices for each product by each supplier in the external database 
has to be kept up-to-date. Even the best data synchronization schedule, however, 
typically does not allow real time synchronization. For example, an external entity 
may receive an erroneous confirmation for an order placed prior to the next scheduled 
synchronization. During the next synchronization, the system may then realize that 
the true inventory level of the ordered product is below the quantity requested by the 
external entity. Thus, even with an external interface, the external entities remain 
unable to communicate with the seller/agent or with each other in real time. 

Thus, it is desirable to provide methods and systems for improved 
procurement services that are capable of operating in a highly automated manner 
and/or allowing communication of procurement information to and among external 
entities. 

SUMMARY 

A computer system may be configured to provide highly automated 
procurement services. The computer system is coupled to a plurality of trading 
partners via a set of connection networks. A database accessible by the computer 
system is initialized with information fi-om one or more trading partners. Examples of 
initialization information include pricing, terms and conditions, and purchase forecast 
mformation. A trading partner may be a supplier trading partner, a customer trading 
partner, or another entity depending on the applicable transaction. 

In one exemplary embodiment, the computer system may be configured to 
receive a purchase request firom a first trading partner and, in response thereto, 
automatically^ select at least one qualified trading partner^ &om the available trading 



' Of course, the system could also be configured to allow occasional manual selection (e.g., overrides) 
or a combination of manual and automatic selectioa 



partners, generate a purchase order based at least in part on the purchase request, and 
forward the purchase order to the selected qualified trading partner. The qualified 
trading partner may be selected based on those whose information has previously 
been placed in the database (e.g., upon initialization or at any other point prior to this 
transaction) and the purchase request. Alternatively, the qualified trading partner may 
be added in connection with the purchase request. 

After receiving the purchase request, the quaUfied trading partner may enter an 
acknowledgment into the computer system via its communication device. The 
computer system may be configured to automatically^ process the acknowledgment, 
optionally including forwarding the acknowledgment to the first trading partner. Prior 
to granting access to a trading partner, the computer system may require the trading 
partner to authenticate itself or otherwise verify its identity. For example, a trading 
partner may have to log in before placing a purchase request. 

In connection with fulfillment of the purchase order, the quahfied trading 
partner may wish to enter a shipment notice into the computer system. In an 
exemplary embodiment, the computer system may be configured to receive a 
shipment notice firom the quaUfied trading partner, automatically^ forward the 
shipment notice to the first trading partner, create an accounts payable file, create an 
accounts receivable file, and/or forward the accounts payable and accounts receivable 
files to an accounts payable database and an accounts receivable database, 
respectively. 

From time to time, a trading partner may not act entirely in accordance with 
the terms and conditions, or purchase forecasts, that were stored into the database. 
Accordingly, in an exemplary embodiment, the computer system may be configured 
to automatically^ detect an exception and generate an exception report. If the 
exception is not acceptable to an involved trading partner, an escalation process may 
be requested by that involved trading partner. In one embodiment, the computer 
system may attempt to resolve the escalation request by forwarding the escalation 
request to customer service. Customer service may negotiate with at least one of the 



^ One or more trading partners may be selected to fulfill each purchase request, depending on 
information in the database. 



involved trading partners and/or forward the negotiation result to at least one other of 
the involved trading partners. 

Sometimes, after placing an order, a trading partner may wish to change the 
order (e.g. quantity of the order). Accordingly, in an exemplary embodiment, the 
computer system may be configured to automatically^ forward a change order request 
received from that trading partner to the other involved trading partner(s). In 
addition, the computer system may be configured to automatically detect any 
exception in the change order transaction. If a detected exception is unacceptable to 
one of the involved trading partners, the computer system may further be configured 
to resolve the exception and/or an escalation request (as described above or 
otherwise). 

In an exemplary embodiment, a trading partner may also wish to enter 
purchase forecast information into the computer system. The computer system may 
be configured to receive the purchase forecast information and, in response thereto, 
automatically' select at least one qualified trading partner, forward the purchase 
forecast information to that at least one quahfied trading partner, and/or store the 
purchase forecast information in the database. Again, during this process, the 
computer system may be configured to automatically' detect any exception. If a 
detected exception is unacceptable to one of the involved trading partners, the 
computer system may further be configured to resolve the exception and/or an 
escalation request (as described above or otherwise). 

BRIEF DESCRIPTION OF THE FIGURES 

FIGURE 1 illustrates a system in accordance with an exemplary embodiment. 

FIGURE 2 illustrates sai initialization process in accordance with an 
exemplary embodiment. 

FIGURE 3 illustrates an order management process in accordance with 
another exemplary embodiment. 

FIGURE 4 illustrates a customer-initiated change order process in accordance 
with another exemplary embodiment. 

FIGURE 5 illustrates a supplier-initiated change order process in accordance 
with another exemplary embodiment. 



FIGURE 6 illustrates a forecast process in accordance with another exemplary 
embodiment. 

FIGURE 7 illustrates an order fulfillment process in accordance with another 
exemplary embodiment. 

DETAILED DESCRIPTION 

Figure 1 illustrates an exemplary overall system 100 for providing highly 
automated"^ procurement services in accordance with a transaction. The system 100 
includes communication devices 102a-d coupled to and/or accessible by a plurality of 
trading partners'^, such as customers and supphers, a set of connection networks 104a- 
d coupled to the communication devices 102a-d, and a computer system 106 that is 
capable of communicatmg with the pluraUty of trading partners via the set of 
connection networks 104a-d and the communication devices 102a-d. 

In an exemplary embodiment, each of the plurality of trading partners is 
registered with the computer system 106. In one aspect of this embodiment, each 
registered trading partner is provided with a log-in name and/or a password or other 
verification mechanism for accessing the computer system 106. In an exemplary 
embodiment, the computer system 106 is controlled by software configured to provide 
highly automated procurement services in accordance with the embodiments. Any 
computer system capable of fast data processing, for example, a server computer, 
together with software written in any programming language executable on such 
computer, and any necessary databases or other ancillary subsystems, may be used to 
implement the various embodiments. Such implementation details may be varied in 
accordance with the available computing infi-astructure and the desires of the system 
users, and need not be described in further detail here. In addition, the various 
processes described below as performed by or in connection with the computer 

^ The degree of automation can be varied to suit the needs of particular in^lementations. Thus, in 
some systems, the automation can be absolute, while others might be configured to allow a 
combination of manual and automatic operation (e.g., manual overrides). Thus, as used throughout this 
description, the term "automated" (including all its variants) should be understood to include a range of 
operations, all of which contain significant - and possible but not necessarily absolute - automation. 

As used herein, when communicating with a trading partner, it is understood that such communication 
is performed via one or more of the communication devices 102a-d that are coupled to and/or are 
accessible by the trading partner. 



system 106 can be implemented as subsystems or sub-modules to computer system 
106, depending on the particular implementation. Further, while many exemplary 
processes will be described in various exemplary embodiments, various subsets or 
combinations of (including possibly all) such processes may be utilized in accordance 
with specific implementations. 

The computer system 106 typically has access to a database 108 that maintains 
inventory, pricing, terms and conditions, purchase forecasts, and other information 
about the plurality of trading partners for faciUtating transactions among the trading 
partners in substantially real time. As used here, the term "substantially" includes 
communications that occur in actual real time and communications that occur close to 
real time, depending on the particular embodiment implemented. 

In an exemplary embodiment, the set of connection networks 104a-d includes 
connections via the Internet using the RosettaNet business process standards and 
extensible markup language (XML) data format 104a, the EDI (i.e., private electronic 
messaging service based on a collection of standard message formats and element 
dictionary) 104b, Web portal 104c (e.g., via a browser that is connected to the 
Internet for communications via user interfaces, scripting languages, email, and/or 
other well known Web mechanisms), and other communication means 104d (e.g., 
mail, fax, phone, etc.), as appropriate. Through the set of connection networks 104a- 
d, each registered trading partner may receive orders, change orders, cancel orders, 
send forecast files, enter shipment information, check order status, forecast status, 
and/or perform other applicable processes through the computer system 106 in a 
highly automated manner. 

For ease of explanation, the exemplary processes described in Figures 2-7 
below are described in the context of a customer trading partner and a supplier trading 
partner. In practice, however, there is no limitation to a single trading partner at each 
end of the transaction. In other words, multiple trading partners may access the 
computer system 106 at the same time and may be involved in the same transaction, 
in overlapping transactions, or in other related transactions. In addition, a trading 
partner may be a customer trading partner, a supplier trading partner, or still other 
parties, depending on the apphcable transaction. Further, as used herein, a suppUer is 



not restricted to a manufacturer of goods or direct provider of services, but could be a 
reseller, distributor, marketing or sales agent, or any other intermediary or other party 
involved in the supply process. 

Figure 2 illustrates an initialization^ process in accordance with an exemplary 
embodiment. At step 202, suppUer information from suppUer trading partners is 
estabUshed. In an exempl^ embodiment, suppher information may be obtained by 
personnel at the seller/agent from each suppUer trading partner. Alternatively, a 
supplier trading partner may fill out a form or otherwise provide information to the 
seller/agent. Examples of supplier information with respect to a suppher trading 
partner include preferred connectivity information (e.g., via EDI, RosettaNet, or other 
communication means), pricing, payment terms, and/or other contractual terms and 
conditions (hereinafter "suppUer information"). The estabUshed suppUer information 
is stored into the database 108 via the computer system 106 (step 204). In an 
exemplary embodiment, at step 204, mapping fimctions that map related suppUer 
trading partners to each other (e.g., trading partners that offer the same product) are 
also performed. 

Likewise, customer information from customer trading partners is estabUshed 
(step 206). Examples of customer information include preferred connectivity 
information, purchase forecasts, and/or other confractual information (hereinafter 
"customer information"). The established customer information is stored into the 
database 108 (step 208) via the computer system 106. In an exemplary embodiment, 
if a customer trading partner wishes to make a purchase via the seller/agent, a 
business project identification (e.g., a unique sequential number) is assigned to the 
business project involving the customer trading partner and potentially one or more 
supplier trading partners. Customer information relating to that customer trading 
partner is associated with each business project identification related to that customer 
trading partner. 



The data input processes described herein are typically performed during initialization, but could also 
be performed at some other stage, for example, as part of updating. Thus, the term initialization should 
be understood to include not only the first, but also any subsequent data entries, so long as the data are 
entered prior to or at the time of use. 



In an exemplary embodiment, for each business project, personnel at the 
seller/agent may identify one or more potential supplier trading partners who might be 
able to fulfill the customer trading partner's requirements. For example, a customer 
trading partner may be mapped to one or more potential suppher trading partners, who 
may be capable of fulfilling the forecast quantities specified in a business project. 
The mapping information (e.g., information relatmg to each set of customer and 
suppner(s) that are mapped to each other) is entered into the database 108 via the 
computer system 106 (step 210). 

Next, business rules are established for automatically^ resolving issues arising 
out of or relating to business projects (step 212). For example, if more than one 
potential supplier trading partners are identified for a business project associated with 
a customer trading partner, business rules are estabhshed to allow the computer 
system 106 to automatically^ decide which potential supplier trading partner(s) should 
be selected to fulfill each purchase request arising out of that business project. For 
example, if five potential supplier trading partners are identified for a business 
project, in response to receiving a purchase request arising out of that business 
project, the computer system 106 may automatically' select two out of the five 
potential supplier trading partners (i.e., two qualified supplier trading partners) to 
fulfill that purchase request because so selecting yields the highest profit margin for 
the seller/agent, meets the customer trading partner's required delivery schedule, 
and/or other reasons set by the business rules. 

In addition, business rules may also be established to allow the computer 
system to automatically' decide how fulfillment of a purchase request should be spHt 
among selected quaUfied suppher trading partners (i.e., percentage to be allocated to 
each qualified supplier trading partner). In one example, the business rules may allow 
the computer system 106 to automatically' split an order based on a percentage 
combination that yields the highest profit margin for the seller/agent (e.g., 40% by 
qualified suppher trading partner A and 60% by quahfied supplier trading partner B), 
In another example, the business rules may allow the computer system 106 to 
automatically' split an order based on a percentage combination that meets the 
delivery schedule required by the customer trading partner. In yet another example, 
business rules may include rules relating to minimum/maximum order quantity and 
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delivery schedules. The established business rules are entered into the database 108 
via the computer system 106 (step 214). 

Information specific to each business project (e.g., different shipment 
addresses for each potential supplier trading partner) and/or specific to each product is 
also stored into the database 108 via the computer system (step 216). 

In an exemplary embodiment, the initialization process may be performed by 
personnel at the seller/agent who maintain the computer system 106. For example, 
information is gathered from or about trading partners then entered into the computer 
system 106 by such personnel. In this embodiment, the system is configured to 
provide appropriate data entry screens to be used by the personnel to enter 
information. Alternatively, such information could (in whole or in part) be entered by 
the trading partners themselves. 

Figure 3 illustrates an order management process in accordance with an 
exemplary embodiment. At step 302, a customer trading partner^ places a purchase 
request via a connection network 104 coupled to the computer system 106. In an 
exemplary embodiment, the pvirchase request is associated with business project 
having a previously assigned business project identification (see step 206 in Figure 2). 
In one embodiment, using the business project identification, the computer system 
106 may be configured to look up related business rules and other information (e.g., 
supplier information, customer information, mapping information, business project 
related information, etc.) stored in the database 108 for automatically^ selecting at 
least one qualified suppher trading partner to fiilfiU the purchase request and, if more 
than one qualified supplier trading partners are selected, allocating the order among 
the quahfied supplier trading partners. 

The computer system 106 is configured to automatically^ create a purchase 
order based on the purchase request (step 304). In an exemplary embodiment, the 
purchase order may include the business project identification associated with the 
purchase request, information related to one or more selected qualified supplier 
trading partner (e.g., preferred connectivity to each qualified supplier trading partner, 
price for the requested product, etc.), information to be sent to one or more selected 
qualified suppKer trading pMtner (e.g., quantity of the requested product, shipment 
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address, delivery schedule, etc.), and other information generally related or specific to 
this purchase request. 

In an exemplary embodiment, price confidentiality is maintained by 
configuring the computer system 106 to select one or more qualified suppher trading 
partners without revealing to the customer trading partner different prices offered by 
the selected qualified supplier trading partners. Likewise, the computer S3^tem 106 
may be configured to not reveal to the selected one or more quahfied supplier trading 
partners the purchase price agreed to by the customer trading partner. 

Next, the computer system 106 forwards the pxirchase order to the selected 
quahfied suppher trading partner(s) (e.g., via the preferred connectivity associated 
with the selected quahfied supplier trading partner(s)). In an exemplary embodiment, 
the qualified suppher trading partner may also receive an email or alert from the 
computer system 106 indicating that a customer trading partner is awaiting an 
acknowledgment for its purchase order. The qualified supplier trading partner(s) may 
enter an acknowledgment of the purchase order, via a connection network 104, into 
the computer system 106 (step 306). The computer system 106 reviews the received 
acknowledgment from the suppher trading partner and forwards the acknowledgment 
to the customer trading partner (step 308). In an exemplary embodiment, at step 308, 
the computer system 106 may also be configured to automatically* detect (with or 
without human assistance) an exception in the acknowledgment. For example, an 
exception could be detected when the qualified suppher trading partner is unable to 
fulfill the quantity (or some other specification) requested in the purchase order 
contrary to the suppher trading partner's agreed to terms and conditions. 

If an exception is detected, an exception report (e.g., an email or alert) may be 
generated and forwarded to customer service, which typically includes at least some 
human personnel (preferably live, but possibly also with delayed response) or other 
suitable means (for example, sophisticated automated customer service software) for 
exception resolution (step 310). In an exemplary embodiment, the computer system 
may also forward the information in the acknowledgment in addition to or as a part of 
the exception report. The exception report thus generated and forwarded can be used 
for a variety of purposes appropriate to the needs of the particular implementation, 
including without limitation, monitoring supplier performance, providing information 
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to customer service for exception resolution, or other feedback or record keeping 
purposes. 

Next, the exception report forwarded to customer service may indicate 
whether the customer trading partner has requested to be involved when an exception 
is detected (step 312). In one embodiment, whether or not a trading partner wishes to 
be involved when an exception is detected could have been entered into the computer 
system 106 during an earlier initialization process (e.g., see Figure 2). Alternately, 
customer service may determine, independently of the exception report, to negotiate 
with one or more of the involved trading partners to resolve the exception. If the 
customer does not wish to be involved, the process ends (step 3 14). If, on the other 
hand, it is determined that the customer trading partner is to be involved, customer 
service can contact the customer trading partner via the computer system 106 to 
determine if the exception/acknowledgment is acceptable (step 316). The customer 
trading partner reviews the exception/acknowledgment (step 318). 

If the acknowledgment is unacceptable to the customer trading partner, an 
escalation process in the computer system 106 can be initiated, either automatically^ 
or by the customer trading partner (step 320). An escalation process request is 
forwarded to customer service (whether software-based and/or with a human 
component) via the computer system 106 (step 324) where customer service attempts 
to resolve any issues by negotiating with one or more of the involved trading partners 
(step 326). The result of the negotiation^ can be forwarded to the customer trading 
partner via the computer system 106 (step 328) and the appropriate network 104. 

Referring back to step 320, if the acknowledgment is acceptable to the 
customer trading partner, the process ends (step 322). 

Figure 4 illustrates a customer-initiated change order process in accordance 
with an exemplary embodiment. At step 402, a customer trading partner initiates a 
change order request and enters the request into the computer system 106. The 
computer system 106 automatically^ forwards the change order request to one or more 
qualified supplier trading partners who are involved in the transaction where the 
change order request originated (hereinafter 'the supplier trading partner") (step 404). 

*^ An involved trading partner may refuse to negotiate. In such a case, the result of the negotiation 
includes a refusal to negotiate by that involved trading partner. 
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In an exemplary embodiment, at step 404, the computer system 106 may also 
automatically^ detect any exception in the change order request. If an exception is 
detected (e.g., the customer trading partner now wishes to order more or less than its 
forecast quantity), the computer system 106 may generate an exception report and 
forward the exception report (including or along with the change order request) to 
customer service (step 412). The supplier trading partner reviews the change order 
request and determines a response (step 406), then updates the computer system 106 
with the response (step 408). The computer system 106 may automatically^ forward 
the response to the customer trading partner (step 410). In an exemplary embodiment, 
at step 410, the computer system 106 may also automatically^ detect an exception in 
the response. If an exception is detected (e.g., the supplier refuses to accept the 
change order even though it falls within the customer's forecast quantity), an 
exception report may be generated and forwarded (including or along with the 
response) to customer service (step 412). When the customer trading partner receives 
the supplier trading partner's response, the customer trading partner determines 
whether the response is acceptable. If the response is not acceptable, an escalation 
process is requested (step 414). The escalation process request can be forwarded by 
the computer system 106 to customer service, which can attempt to resolve any issues 
by negotiating with at least one of the involved trading partners^ (step 418). If the 
supplier trading partner agrees to changes that are acceptable to the customer trading 
partner (step 420), the suppHer trading partner can enter the appropriate changes into 
the computer system 106 (step 422), such changes can be automatically^ forwarded to 
the customer trading partner (step 424). 

Referring back to step 420, if the supplier trading partner canjiot/does not 
agree to changes that are acceptable to the customer trading partner, customer service 
can optionally determine if the customer trading partner wants to make any more 
changes (modifications, cancellation, etc.) to its order (step 426). If not, the customer 
trading partner is notified of the final result via the computer system 106 (step 428). 
If, however, the customer trading partner wants to make more changes (e.g., the 
customer trading partner may decide to go back to its original order which was 
acceptable to the supplier trading partner), the changes are reviewed with the 
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customer trading partner (step 430) and the customer trading partner is notified of the 
final result via the computer system 106 (step 432). In an exemplary embodiment, the 
supplier trading partner is also notified of the final result via the computer s)^tem 106 
(not shown). 

Referring back to step 414, if no escalation process is requested, the customer 
trading partner determines whether any other changes to the order is needed (step 
434). If not, the process ends (step 436). If more changes are needed, those changes 
are made (step 438), then the process ends (step 436). In an exemplary embodiment, 
if more changes are needed at step 438, the process may begin again at step 402 for 
those additional changes. 

Figure 5 illustrates a supplier-initiated change order process in accordance 
with an exemplary embodiment. At step 502, a supplier trading partner initiates a 
change order request and enters the request into the computer system 106 (e.g., the 
supplier trading partner may request a change in the delivery date). The computer 
system 106 is configured to automatically^ forward the change order request to a 
customer trading partner who is involved in the transaction where the change order 
request originated (step 504). In an exemplary embodiment, at step 504, the computer 
system 106 may automatically^ detect any exception in the change order request. If 
an exception is detected (e.g., the supplier trading partner now refiises to fiilfiU an 
order of an agreed-to quantity or some other specification), the computer system 106 
may generate an exception report and forward the report (including or along with 
information in the change order request) to customer service (step 512). 

The customer trading partner can review the change order request and 
determine a response (step 506), then update the computer system 106 with the 
response (step 508). The computer system 106 may automatically^ forward the 
response to the suppher trading partner (step 510). In an exemplary embodiment, at 
step 510, the computer system 106 may also automatically^ detect any exception in 
the response. If an exception is detected (e.g., the customer refiises to accept the 
change order even though the new quantity falls within the supplier's agreed to 
quantity), an exception report may be generated and forwarded (including or along 
with information in the response) to customer service (step 512). When the supplier 
trading partner receives the customer trading partner's response, it determines 
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whether the response is acceptable. If the response is unacceptable, the supplier 
trading partner may make an escalation process request (step 514). The escalation 
process request is forwarded by the computer system 106 to customer service, which 
can attempt to negotiate with at least one of the involved trading partners^ (step 516). 
If the customer trading partner agrees to changes that are acceptable to the supplier 
trading partner (step 518), the customer trading partner then inputs the changes into 
the computer system 106 (step 520). The computer system 106 may automatically 
forward the final change results to the supplier trading partner (step 522). 

Referring back to step 518, if customer trading partner cannot/does not agree 
to changes that are acceptable to the suppUer trading partner (e.g., customer does not 
agree to the new delivery date), customer service may determine whether the supplier 
wants to make any more changes to its order (e.g., to change back to the original 
delivery date) (step 524). If not, the supplier trading partner is notified of the final 
result via the computer system 106 (step 522). If supplier wants to make more 
changes, the changes are reviewed with the supplier (e.g., the supplier may agree to 
honor the original delivery date) (step 526) and the suppKer trading partner is notified 
of the final result via the computer system 106 (step 522). In an exemplary 
embodiment, the customer trading partner is also notified of the final result via the 
computer system 106 (not shown). 

Referring back to step 514, if no escalation process is requested, the supplier 
trading partner can determine whether any other changes to the order is needed (step 
528). If not, the process ends (step 532). If more changes are needed, those changes 
can be made (step 530), then the process ends (step 532). In an exemplary 
embodiment, if more changes are needed at step 530, the process may begin again at 
step 502 for those changes. 

Figvire 6 illustrates a forecast process in accordance with an exemplary 
embodiment. At step 602, a customer trading partner initiates (or enters) forecast data 
into the computer system 106. The computer system 106 is configured to 
automatically^ forward the forecast data to at least one qualified supplier trading 
partner (step 604). In one embodiment, the computer system 106 may automatically^ 
select one or more qualified supplier trading partner based on the business rules and 
information stored in the database 108. For example, the forecast data may be 
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associated with a business project that has a previously assigned business project 
identification. Using the business project identification, the computer system 106 
may be configured to look up related business rules and information stored in the 
database 108 to select the quaUfied supplier trading partner(s). 

In an exemplary embodiment, at step 604, the computer system 106 may also 
automatically detect any exception. If an exception is detected (e.g., when the new 
forecast quantity is more than the original forecast quantity), an exception report may 
be generated and forwarded (including or along with information in the forecast data) 
to customer service (step 606). After receiving the forecast data, the suppher tirading 
partner may request an escalation process because the forecast is unacceptable (step 
608). If an escalation process is requested, the request is forwarded to customer 
service by the computer system 106. Customer service may attempt to resolve any 
issues by negotiating with at least one of the involved trading partners^ (step 610). If 
the customer trading partner wants to make more changes (step 612), the customer 
trading partner may input modified forecast data into the computer system 106 (step 
614). The modified forecast data may be automatically^ forwarded via the computer 
system 106 to the quahfied suppher ti-ading partner (step 616). In an exemplary 
embodiment, if more changes are made at step 612, the process may begin again at 
step 602 for those changes. 

Referring back to step 612, if the customer ti-ading partner does not want to 
make any more changes, it is determined whether the supplier ti-ading partner wants to 
make any changes (e.g., to accept the forecast data even though it is more or less than 
the original forecast quantity) (step 618). If so, customer service reviews the changes 
with the suppher tiading partner (step 620) and the computer system 106 forwards the 
final results to the supplier tirading partner (step 616). hi an exemplary embodiment, 
the customer trading partner is also notified of the final results via the computer 
system 1 06 (not shown) . Referring back to step 6 1 8 , if the supplier trading partner 
does not want to make any changes, the computer system 106 forwards the fmal resuh 
to the suppher trading partner (step 616). 

Figure 7 illustrates an order fiilfiUment process in accordance with an 
exemplary embodiment. At step 702, a suppher trading partner ships an ordered 
product to a customer trading partner. In an exemplary embodiment, at step 702, the 
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supplier trading partner also sends shipping information and/or invoice information to 
the customer trading partner and/or accounts payable database maintained by the 
seller/agent, respectively. Next, the supplier trading partner may enter a shipment 
notice into the computer system 106 (step 704). In one embodiment, the shipment 
notice may include information such as shipment carrier name, shipment tracking 
number, etc. The computer system 106 automatically^ forwards the shipment notice 
to the customer trading partner (step 706) who is to receive the product. In an 
exemplary embodiment, the computer system 106 may also automatically^ create or 
update an accounts receivable file and/or an accounts payable file based on the 
shipment information (step 708) and forward the files to accounts receivable and/or 
accounts payable databases, respectively. In an exemplary embodiment, the accounts 
receivable database and/or the accounts payable database may be maintained by the 
computer system 106 or by a separate seller/agent's finance system that is accessible 
by the computer system 106. 

Based on the accounts receivable file, the computer system 106 or the finance 
system may generate an invoice and send it to the customer trading partner via the 
computer system 106 (step 710). When the customer trading partner receives an 
invoice, it matches the shipping information fi-om the supplier trading partner and 
pays the seller/agent via the computer system 106 (step 712). The payment is applied 
in the accounts receivable database via the computer system 106 and/or the finance 
system (step 714). 

Based on the accounts payable file, the computer system 106 or the finance 
system may match the invoice received fi-om the suppUer trading partner and make a 
payment via the computer system 106 to the supplier trading partner (step 716). The 
payment may be applied and updated in the accounts payable database via the 
computer system 106 and/or the finance system (step 718). 

In an exemplary embodiment, the payment received fi-om the customer trading 
partner at step 712 is not the same amount as the payment to the supplier trading 
partner at step 718. The computer system 106 may optionally apply a mark-up 
amount (and may add such an amount to the invoice prior to forwarding the invoice to 
the customer trading partner) depending on the specific implementation. 
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Trading partners may be given direct, substantially real time access to the 
computer system 106 for making changes to initialized information (e.g., forecast 
quantity changes, prices changes, inventory changes, etc.) stored in the database 108 
and order information. Thus, information stored in the database 108 is substantially 
current and transactions among trading partners are processed in substantially real 
time in a highly automated manner. 

In an exemplary embodiment, a new trading partner, whether customer or 
supplier, may be added where at least one of the trading partners is not known prior to 
receiving a purchase request in a transaction, but is identified in connection therewith. 
For example, a new customer trading partner may register just prior to submitting a 
purchase request and a new suppUer trading partner may be identified in that purchase 
request. A new supplier or customer trading partner may be added to the computer 
system 106 by the seller/agent's authorized personnel 

The foregoing examples illustrate certain exemplary embodiments from which 
other embodiments, variations, and modifications will be apparent to those skilled in 
the art. The inventions should therefore not be limited to the particular embodiments 
discussed above, but rather is defined by the claims. 
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